home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 175 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.6 KB
  1. Date: Wed, 1 Jun 1994 12:30:04 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: Colour.
  4. To: gem-list@world.std.com
  5. In-Reply-To: <199406010451.AA247445050@relay2.geis.com>
  6. Message-Id: <Pine.3.87.9406011204.B2199-0100000@undergrad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11.  
  12. On Wed, 1 Jun 1994 s.sanders2@genie.geis.com wrote:
  13.  
  14. > Reply:  Item #5728781 from GEM-LIST-APPROVAL@WORLD.STD.COM@INET00#
  15. >  
  16. > Timothy Miller:
  17. >  
  18. > Actually, it would be better if the request could specify whether
  19. > a 'close' color was OK and to return the color if it actually got if
  20. > an exact request couldn't be honored. Likewise if the app demands a
  21. > specific color the call would fail if an exact match couldn't be
  22. > satisfied.
  23.  
  24. I don't think it should fail.  Since the app is going to have its own 
  25. palette anyway, the manager should find the closest color and replace 
  26. it.  However, the problem with this is if more than one request ends up 
  27. finding that the same palette entry is the closest for all of them, 
  28. defeating the purpose.  There should be facilities for supplying a 
  29. partial palette and the manager makes necessary changes to the palette 
  30. and reports back a list of entry numbers... this way, the manager 
  31. wouldn't allow for two colors to end up accidentally in the same palette 
  32. entry.
  33.  
  34. >  
  35. > Simon:
  36. >  
  37. > I don't believe the user should be encouraged to edit .RSC files
  38. > under _any_ circumstances. If you want editable keyboard equivalents,
  39. > that's fine, just put it in the program as an option. That would
  40. > probably be less work and safer than scanning for key char names
  41. > anyway.
  42.  
  43. I agree with this.
  44.  
  45. >  
  46. > -Scott @ SDS
  47. >  
  48. >  
  49. >  
  50. > 
  51.  
  52.